When linking an embedded application into a target processor, decisions are made as to where to place code and data in various memories of the hardware. Some of the code or data might be placed in the memories that “shadow” or “overlay” each other. This is particularly needful where the addressing capability of the processor (typically called address space) is small such as 16 bits on a Digital Signal Processor (DSP) such as for example, on the TMS 320C5402 DSP.
FIG. 1 illustrates the actual memory devices that populate the address space for a typical DSP application with the addresses from 0 to 0xFFF for on-chip RAM (Random Access Memory). The on-chip RAM means that which is on the DSP chip and therefore has the fastest access. The addresses from 0x1000 to 0x7FFF may be off-chip or external RAM. The third area of memory may be from 0x8000 to 0xFFFF or end of memory, may be for flash memory. The flash memory may contain the permanent programs, constants and start up information. The flash memory does not loose everything when the power is removed but is usually slow and therefore not appropriate for running an application. The shadow or overlay memory is used to add more memory to a system without having to extend the target processor's addressing capabilities. In that case a second and maybe a third configuration of the population of the address space is provided. For the example, the second configuration illustrated in FIG. 1, the same on-chip RAM and off-chip RAM that is present with the first configuration is also present in the second configuration, but the address space after 0x8000 that previously had the flash memory now has an off-chip RAM 2 from 0x8000 to 0xFFFF. The system may include a third configuration that also shares the same on-chip RAM and off-chip RAM with the other configurations, but has off-chip RAM 3 in place of the flash or RAM 2. The third configuration of the address space is illustrated in FIG. 1.
The configuration of the system may look like FIG. 2 wherein the DSP is connected to a control switch that determines which memory configurations of flash memory and RAM 2 or RAM 3 is currently addressable by the DSP at addresses 0x8000 to 0xFFFF. A one-bit signal (CB1) is provided to the control switch to switch between the flash memory and the RAM 2 or RAM 3 memory for the addresses between 0x8000 and 0xFFFF. The system may include a second control bit (CB2) to a second control switch to switch between RAM 2 and a third RAM 3 off-chip memory for the addresses between 0x8000 and 0xFFFF. The problem is that the same address range, 0x8000 to 0xFFFF, does not address the same memory. Address 0x8000 may refer to either the first address in flash, RAM 2 or RAM 3 depending on the value of the control bits CB1 and CB2. The configuration of the memory may look as illustrated in FIG. 1 with two control signals. There is for example a two-bit code to identify the three configurations. The first configuration can be indicated by the two control bits set at 00, the second by the control bits set at 10 and the third by the control bits set at 11. Both the address and the configuration must be identified when addressing memory. For example, if the control bits are 00, address 0x8000 refers to the first address in flash memory. If the control bits are 10, address 0x8000 refers to the first address in RAM 2, and if the control bits ate 11, address 0x8000 refers to the first address in RAM 3, and so on.
Software has not been able to effectively deal with multiple memory configurations within the same address space. Some linkers are currently capable of supporting the linking of two pieces of code or data to different memory devices responding to the same address. However post linking tools such as loaders and debuggers have no automated/generalized support for downloading the application to the different memory devices on the target hardware and then debugging an embedded system whose memory map (addressable memory devices) changes as a result of the state of all the hardware control devices. The downloader 37 for example does not know the current memory configuration when it is downloading the application to memory. For the debugger, the system starts where it is going to run, but the debugger does not know what configuration the system is in at any given time during execution. Normal tools do not know the different conditions that determine which shadow memories are addressable. The users must laboriously construct limited one-of a-kind solutions to support download and debug under these conditions.
Typically, values contained in special purpose control bits (CB1 and CB2 for the case in FIG. 1) cause read and write operations to specific addresses to be responded to by different memory devices, depending on the values contained in the control bits. For the case of FIG. 1, if the control bit CB1 holds a 0, a flash memory responds to the read and write requests for the address range 0x8000 to 0xFFFF, and if the control bit is a 1 the shadow external RAM device (RAM 2 or RAM 3) responds to the read and write requests for the address range 0x8000 to 0xFFFF. This presents a burden for the programmers because when calling routines contained in shadow memory or memory that is shadowed, it is sometimes necessary to set the control register bits as part of the calling sequence. The calling sequence must include, for example, a write of 1 to the CB1 control bit and a write of 0 to the CB2 control bit when performing a call to a routine that resides in shadow memory RAM 2 from a code that resides outside of the RAM 2 shadow memory. Similarly, the calling sequence needs to set both CB1 and CB2 to 1 before calling a routine that resides in RAM 3 from code that resides outside of RAM 3.
Typically, programmers manually alter the source code near call sites to change control register settings. Unfortunately, the need to alter source code in response to system integration and memory layout decisions leads to a number of problems. First, the source code for some portions of the embedded application may not be available at system integration time. For example, some code may be supplied as a pre-compiled library. Second, the distribution of code amongst the memories of the embedded system often needs to be altered during system development and tuning. This causes constant maintenance of the placement of source code setting shadow memory control bits. Third, from a process standpoint, it is costly to alter source that has already been tested. Usually, such alterations require a partial or complete re-testing of that source unit. Lastly, the inclusion of a manual step in any process is prone to error, especially when there is not an automated correctness check applied. Control bit operations may be misplaced, forgotten, or duplicated as the application evolves. This leads to increased development time and cost as the bugs are discovered and corrected.
The need to alter source code in response to system integration and memory layout decisions leads to similar problems in connection with the need to alter source code to copy code overlays into fast memory from slow memory. Code overlays also present a burden for the programmers because when calling routines that are part of a code overlay, it is sometimes necessary to copy the code from slow memory to fast memory prior to making the call. The calling sequence must include, for example, code that determines whether the routine being called is already present in the overlay, and code that copies the routine to the code overlay if it is not already present in the overlay.